1. Field of the Invention
The present invention relates generally to databases and, more specifically, to relational databases providing materialized views.
2. Description of the Background Art
A relational database management system (“DBMS”) is a database model that defines relationships between attributes within a relation table. A query is performed on the DBMS in order to obtain a subset of data within the database that addresses a request represented by the query. A result provided by the DBMS as a response to the query can itself be represented as a table. For example, a query on a table “T” having five columns labeled “A”, “B”, “C”, “D”, and “E”, respectively, may identify a subset of the five columns as containing desired information. The example query:select A, B from T where A=‘Sybase’would produce a result that can be interpreted as a two-column table, having columns “A” and “B”, which would be populated only by rows in which the value of column “A” was ‘Sybase’ in base table “T”
A temporary table created as a result of a query is commonly referred to as a “view,” although different database vendors may refer to similar such constructs using other names.
Materialized views go one step further and cache or otherwise store the temporary table as its own entity, separate from the underlying base tables which contain the queried data. Again, different database vendors may refer to similar such constructs using other names, including “summary tables,” “staging tables,” and “indexed views.” By caching the results of a query, these results themselves can be the subject of additional queries without resolving the potentially costly original query again. One skilled in the relevant arts will appreciate that a number of applications are able to take advantage of materialized views in order to significantly improve performance.
A problem arises when an underlying base table which was queried to create materialized view is itself updated. An update of a base table has the potential to render the materialized view obsolete. While this tradeoff may be acceptable in certain contexts, such as when base tables are rarely updated, or when obsolescence of the materialized view is irrelevant to an operation, other contexts require that the materialized view accurately reflect the current state of the database and its underlying base tables.
One solution is to defer maintenance of the materialized view until some future time. For example, some current systems require a user to initiate maintenance of the materialized view through, for example, a “refresh” statement. Although this may again be acceptable in certain contexts, other contexts may require immediate maintenance of materialized views, or “immediate materialized views” (“iMV”). Again, different database vendors may refer to similar such constructs using other names, including “immediately maintained materialized views.”
An iMV is used in contexts where the data within the iMV must always accurately reflect the data in its underlying base tables. Accordingly, when the underlying base tables referenced by an iMV are updated, the iMV should immediately reflect any such applicable changes immediately.
Current database systems implementing iMVs provide for maintenance of the iMVs through either recomputation or incremental maintenance. Recomputation involves the recreation of the entire iMV whenever an underlying base table is updated, typically by recomputing the original query used to generate the iMV. This operation can be costly, and may even defeat the usefulness of the iMV in contexts where frequent updates of the underlying base tables are expected. A preferred solution is to perform incremental updates on the iMV by propagating only the changes caused by an update to an underlying base table to the iMV itself. However, this solution is unavailable in many contexts in current database systems, as it may be difficult to determine precisely what has been updated. For this reason, although incrementally updating the iMV would typically be more desirable than recomputation of the iMV, the option to use an incremental update is often unavailable.
Accordingly, what is desired is a means to enable immediate incremental updates of an iMV that is available in additional contexts with fewer restrictions.